-
-
Notifications
You must be signed in to change notification settings - Fork 324
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade OpenGL backend to ES 3.0 #995
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice to see the 3.0 syntax in the shaders.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Merges and works fine with my pending changes 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me open a pending review before I have the chance to test Qt, should be soon.
No, Qt does not work anymore on macOS. I guess then Node.js would also be broken. What's the motivation to move to GLES 3.0? |
Any platform built for macOS is going to fail with this PR - Qt, node, render-test-runner and so on. Moving to ES 3 gives us a few important features, the two big ones are uniform buffer objects (UBOs) and Vertex array objects (VAOs). Using these, we can significantly simplify the existing GL rendering code and bring it more inline with what we anticipate the coming Metal backend will look like. ES 3 also brings increased minimums on certain implementation limits like number of vertex attributes, which increases to 16 with ES 3, removing one of the reasons for keeping the existing shader permutation system around. The current plan then, is merge this PR and shut off macOS on CI. Existing users on macOS will have to remain on the last stable release until the Metal platform is ready later this year. Once Metal is ready, the darwin platform (and all dependents like glfw, Qt, node) can be moved to the new native backend and revived. The other option is to bridge the gap with ANGLE on mac, but this is extra temporary work until Metal is implemented. This option should only be entertained if there is significant enough demand for it. |
OK, then we should cut releases before this is merged. Also this motivates more repo split as I effectively can't develop anymore mac being my primary platform. To be safe, we should also manually test other platforms I guess (Windows is another platform I'm worried about). Let's discuss this tomorrow how to best proceed (and if you're willing to eventually help supporting Metal in Qt 😉). |
Does Qt not support Metal? |
Qt6 fully supports Metal (Qt5 I'd have to check). The problem is I barely know bits of OpenGL so I'll need help gluing things together. Unfortunately they're missing some Metal examples that they have for Vulcan and D3D11. It will probably be minimal work for an expert though. |
It looks like there are new definitions that should be added to |
Being addressed in #1007 |
@ntadej OK to merge? |
First the CI should be green (so failing tests disabled) 😊 We may want to tag some releases before we merge this though. I'll be travelling tomorrow but I will be available on the weekend. I think @acalcutt also wanted to tag a release before this is merged. Can this wait a few days? I can also merge it when green when I'm ready (and the CI is green). |
Not really I think. This is a blocker for quite a lot of other things. (cc @sjg-wdw) If you want to make a release, it's possible to do it from the |
I tried to do the last node release i wanted to do but it failed to bump the version. wonder if that node-pregyp-githib secret expired @birkskyum ? |
OK, I can also tag from some older commit the way how the release is set-up (only the changelog may not be OK). So from my side you're OK to proceed. |
@acalcutt it hasn't expired |
@acalcutt , unless github has made some updates to their personal token settings (.. they do work on fine-grained repo-scoped personal tokens), my best guess is that it's caused by the branch protection in this repo. Currently the branch protection setting for |
Before we were using that secret to get passed the branch protection on the version bump, since we checked out with that user also. must not be working anymore. ill have to look into it and see if i have the same issue on my fork. not sure the workflow is set up to build a release for a branch..hmm. probably wont be able to look until later |
@ntadej We had a discussion about keeping macOS CI running on In the end @mwilsnd, @alexcristici and me decided against it. We can apply some tricks to make the project build (but not run) for macOS on Hope you can agree with this reasoning. Maybe you can approve the PR explicitly, otherwise I can't merge (without dismissing your review). |
@acalcutt , the token used on the fork, can you see what permissions it has? The one used here has only |
…awable-1 * commit 'f100a4c5d6449307547c2da850db04b12c6a3a95': Minor reorg of defines. Removed more commented code. Removed commented code. Upgrade OpenGL backend to ES 3.0 (maplibre#995) Run macOS workflows only on `opengl-2` branch (maplibre#1012) Roll back linux metrics submit along with macos metrics. (maplibre#1009)
Hi guys. I know it's been a while since this PR was merged, but I'm planning to submit a PR to fix this, please validate my plans:
Is this the correct way of doing this change? Thank you in advance. |
@tdcosta100 , does that depend on the driver used? from this page it seems like mesa does support ES 3.0 |
Nice, I will try to test it creating a GLES 3 surface. If it works, I will just adjust it (Mesa3D doesn't have a libGLESv3.dll file). |
Yeah, it works, but interesting is: the DLL name is libGLESv2.dll, even it holds all the ES 3.0 functions. I will submit a new PR correcting this. |
This PR upgrades the shaders and GL contexts of all platforms (minus darwin) to OpenGL ES 3.0. A large chunk of changes here are in the shaders & generated shader code (mbgl/shaders/, shaders/) where the following changes were made:
#version 300 es
supportlayout (location = n) in
All instances of MBGL_USE_GLES2 have been removed, with older pathways for ES 1 stuff deleted. All context creation methods have been updated to request ES 3 or ES 3 compatible (windows) contexts, save for macOS's CoreGL backend (support here is pending, may be done via ANGLE in the future).